1. Field of Invention
The present invention pertains to the field of information systems. More particularly, this invention relates to commit scope control in hierarchical information processes.
2. Art Background
Information systems are commonly employed in a variety of business-related and other applications. Such information systems typically include information stores such as database management systems and one or more information processes that manipulate data which is persistently stored in the databases. Such information processes may also be referred to as applications.
An information process may be arranged as a hierarchy of nested transactions. Such a nested transaction hierarchy may be arranged as a closed hierarchy that strictly enforces atomicity at each level. Alternatively, such a nested transaction hierarchy may be arranged as an open hierarchy with relaxed atomicity controls at particular levels.
FIG. 1 illustrates an information process 20 which is arranged as a hierarchy of nested transactions 22-30. The transaction 22 is at a top level or root of the hierarchy. The transaction 22 spawns the transactions 24 and 26. The transaction 22 is referred to as the parent of the transactions 24 and 26, and the transactions 24 and 26 are each referred to as a child transaction or a sub-transaction of the transaction 22. The transaction 24 is a root of a corresponding sub-tree in the hierarchy.
Typically, transactions 24 and 26 each generate a corresponding set of data updates which are targeted for an information store 32. The data updates generated by the transactions 24 and 26 may also be referred to as the effects of the transactions 24 and 26 or the results of the transactions 24 and 26.
The child transactions 24 and 26 make their respective data updates visible to their parent transaction 22 upon their completion. The act of a child transaction making its data updates visible to its parent is referred to as committing to its parent. Transactions that commit to their parent are usually referred to as closed transactions. In other words, the commit scope of a closed child transaction is its parent.
The transaction 24 is the parent of the transactions 28 and 30. The child transactions 28 and 30 are usually closed transactions that commit to their parent transaction 24 upon their completion. Typically, the transaction 24 commits to its parent transaction 22 only after both of its child transactions 28 and 30 have completed. The transaction 22 usually commits to the information store 32 only after both of its child transactions 24 and 26 have completed.
Typically, the transaction 22 commits all accumulated data updates to the information store 32 as a single atomic transaction thereby making the data updates visible to all transactions. Such an "atomic" transaction usually ensures that the interrelated data updates generated by the transactions 22-30 are either all made visible or none are made visible in the information store 32 should a system failure occur.
Such a closed nested transaction hierarchy typically provides strict enforcement of atomicity at each level of the hierarchy because the only possible commit scope of a child transaction is its parent. Unfortunately, such a closed nested hierarchy usually sacrifices data concurrency in the hierarchy.
For example, the transaction 30 may have an extended duration that involves extended user interaction. As a consequence, the transaction 30 may require a relatively long time to complete. The transaction 28, on the other hand, may complete relatively quickly. In addition, the transaction 26 may have a need for the data updates generated by the transaction 28.
The transaction 28 being a closed transaction commits to its parent transaction 24 upon its relatively quick completion. The data updates generated by the transaction 28 are then held by the transaction 24 until the extended duration transaction 30 has completed because the transaction 24 usually cannot commit to its parent transaction 22 until all its children have completed. Unfortunately, such a hold up of data updates generated by the transaction 28 can excessively delay the transaction 26 which requires those data updates even though the transaction 28 had completed relatively quickly.
One prior technique for making the data updates of a child transaction available to other transactions prior to the completion of its parent is to allow the child transaction to commit its data updates to an information store directly. A child transaction that commits directly to an information store is referred to as an open child transaction. It is said that such an open child transaction has an open commit scope. For example, the transaction 28 having an open commit scope upon completion commits to the information store 32 thereby making its data updates immediately visible to the transaction 26.
Unfortunately, such direct updates of an information store by open child transactions usually sacrifices the data integrity controls which are provided by a closed hierarchy. For example, a system failure that occurs after the transaction 28 commits to the information store 32 but before the transaction 22 commits to the information store 32 can result in inconsistent data updates being visible in the information store 32.
In summary, a transaction hierarchy that includes open transactions with open commit scopes usually improves concurency by allowing the data updates of open transactions to be more widely visible upon their completion. Unfortunately, such open hierarchies usually sacrifice the data integrity protections provided by closed hierarchies which enforce atomicity at each level.